Abitualmente si consiglia di non promuovere controller di dominio un server che fa già il routing fra reti, ma per chi avesse una disponibilità limitata di macchine e di spesa, c'è la soluzione per la buona convivenza dei due servizi.
Prendiamo in considerazione Windows Server 2003, ma la soluzione qui spiegata funziona sia sul predecessore (Windows 2000 Server) sia sul successore (Windows Server 2008).
Per fare si che i pc entrino in dominio le porte del controller di dominio verso la rete locale devono essere tutte aperte e il DNS deve pubblicare l'indirizzo IP locale.
Per configurare correttamente il DNS bisogna aggiungere alòò registro di sistema le chiavi:
- Value name: PublishAddresses
Data type: REG_SZ
Value data: IP address of the server's local network adapter. If you have to specify more than one IP address, separate the addresses with spaces.
INHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\...
DNS\Parameters - Value name: RegisterDnsARecords
Data type: REG_DWORD
Value data: 0
INHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\...
Netlogon\Parameters
Ora dobbiamo aggiungere (se non è gia esistente) il record A nel DNS che contiene l'indirizzo IP interno del server: clicchiamo sul nome del nostro dominio in Forward Lookup Zones e dal menu Azioni selezioniamo New Host (A)... . Lasciare il nome dell'host vuoto, inserire l'ip interno e cliccare anche su Create Associated PTR Record e dare OK. Nella stessa cartella facciamo la stessa cosa sotto MSDCS \ GC. Ignorate i messaggi di warning.
Nel sito Microsoft Support c'è la soluzione anche per server WINS.
Ora, se nel servizio di Routing e Accesso Remoto avete impostato dei filtri per connessione Internet, lo avrete fatto certamente sull'interfaccia interna, perchè su quella esterna (connessa al router ADSL) impostare dei filtri significa bloccare la connettività in uno o in un altro verso, inoltre questa è l'interfaccia su cui è attivo il NAT, per cui se si filtrano alcune porte e l'IP esterno del server, è come se i filtri sulle porte non ci fossero, perchè il NAT lavora considerando i filtri tutti allo stesso livello.
Per ovviare al problema basta quindi aggiungere ai filtri interni (l'interfaccia che non ospita il NAT) l'indirizzo IP interno del server. Se ad esempio i filtri sono impostati su quelli in uscita, allora bisognerà aggiungere questa voce:
Rete di Origine: 192.168.0.1 (è, ad es., l'ip del server interno)
Net Mask: 255.255.255.255 (perchè stiamo parlando di machera di rete, non di sottorete).
Dare OK.
In questo modo il server apre tutte le sue porte all'interno della rete, pur continuando a filtrare il traffico Internet che proviene dalla scheda esterna. I filtri saranno tanto più invisibili quanto sarete precisi nell'aprire tutto il set di porte necessarie; inoltre è consigliabile lasciare passare tutte le comunicazioni ICMP.
2 commenti:
Ciao Johnny..mi sono un po' perso nelle tue ultime righe.. ho riprodotto la situazione nella mia LAN strutturando un scenario del tipo: LAN interna (10.0.20.0/24) - Server Int. Interna (10.0.20.1/24) - Server Int. Ext (10.0.10.1) - router (10.0.10.254). Sul server ho installato RRAS senza firewall e senza filtri. Tutto funziona tranne il ping dal router all'interfaccia interna del server.Perche'? Se non ci sono filtri dovrebbe esser permesso il traffico da 10.0.10.0/24 a 10.0.20.0/20. Mi piacerebbe capire perche' non funziona. Ciao e complimenti per il blog.
il ping fa parte delle comunicazioni ICMP, che sono abilitate perchè hai detto che non ci sono filtri. non capisco cosa intendi per "ping dal router": forse che il router fa il ping all'interfaccia interna del server. in questo caso credo che non funzioni poichè bisogna controllare a quale gateway e dns punta il router: se è, come è probabile, il dns e il gateway di un provider, allora il comportamento del ping è corretto, perchè è impossibile per il router risolvere indirizzi interni alla rete privata.
thanks for visiting
Johnny
Posta un commento